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ABSTRACT 

Hrhe  rapid  advances  in  the  development  of  low-cost  computer 
hardware  have  led  to  many  proposals  for  the  use  of  this  hardware 
to  improve  the  performance  of  database  management  systems.  Usu¬ 
ally  the  design  proposals  are  quite  vague  about  the  performance 
of  the  system  with  respect  to  a  given  data  management  applica¬ 
tion.  In  this  paper  we  develop  an  analytical  model  of  the  per¬ 
formance  of  a  conventional  database  management  system  and  four 
generic  database  machine  architectures.  This  model  is  then  used 
to  compare  the  performance  of  each  type  of  machine  with  a  conven¬ 
tional  DBMS.  We  demonstrate  that  no  one  type  of  database  machine 
is  best  for  executing  all  types  of  queries.  We  also  show  that 
for  several  classes  of  queries  certain  database  machine  designs 
which  have  been  proposed  are  actually  slower  than  a  DBMS  on  a 
conventional  processor. 
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t  Ion  to  Hint  record  a  that  aatlafy  a  certain  criterion.  Given  not  do  well  on  a  particular  operation  and  conaequently  add  a  new 
thia  building  block,  other  relational  databaae  opera  tor  a  euch  aa  wart  to  fix  each  bottleneck  dlecovered.  ft  third  problea  with 
Join,  project,  and  aggregate  functlone  can  be  tapleaented  with  cohering  apeclflc  aachinee  la  that  many  of  the  propoaed  dcalgna 
_  are  rooted  In  apeclflc,  and  frequently  different,  technolog  lea. 

*  Including  Dim  (00*179].  In  attempting  to  coapare  theae  dealgna  we  often  found  oureelvea 


comparing  *jpplra 


unit  of  ito[<9«.  Sine*  fixed  heed  dieke  ere  being  phssed  out  of 


IKANN7SJ.  Another  poesible  reeeon  for  teking  thle  route  is  the 
apparent  leek  of  success  of  beed-per -track  disks  ss  secondsry 
storage  devices.  Moving  heed  disks  with  persUel  readout,  on  the 
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The  second  phase  of  tii*  aort-aerge  Join  algoritha  it  to  froa  the  current  tuple  In  8.  The  result  relation  la  produced  by 
■ergo  the  two  sorted  relations  enlttlng  tuples  that  satisfy  the  'Joining*  each  tuple  In  8  with  all  the  tuples  fro*  »  returned  by 
Join  condition.  We  have  also  assuaed  that  the  aerge  step  of  the  the  execution  of  Its  subqusry. 

algor  It  ha  can  be  perforasd  by  reading  each  block  of  both  sorted  The  following  foraulas  express  the  Join  execution  tiae  for 
relations  exactly  once.  While  this  assu^tlon  Is  generally  the  PPT,  PPB,  and  PPD  designs  assualng  that  relation  8  contains 


7  wa  h»v*  iiniHd  that  tha  block*  of  R  and  8  ara  Intarnally 
aortad  on  tha  join  attributa.  Saa  (BORA801  for  a  daacciption  of 
paraUal  updata  algorithaa  that  alwaya  iaava  block  a  aortad. 
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ilgoriths  is  dominated  by  reading,  broadcasting,  and  processing 


•99**9*t*  partition  valuta  can  ba  aatlaatcd 


Hast  a  ptpallnad-parallal  binary  aarga  (saa  (BOAA80) )  la 


Table  i  executing  aoee  operations,  the  effective  processor  utilisation  Is 

50,000  Tuples  of  Size  100  bytes 


algorithms  and  than  extract  the  primitive  operationa  which  ara  7.  References 
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